The Windows Embedded operating system includes functionality that can prevent the content of a storage medium from being changed. In a typical example, it may be desirable to prevent the operating system image, which may be stored on a particular disk partition or on flash media, from being changed at runtime. To accomplish this, Windows Embedded provides a file-based write filter which operates at the file level and an enhanced write filter (or sector-based write filter) that operates at the sector level to redirect all writes that target a protected volume to a RAM or disk cache called an overlay. This overlay stores changes made to the operating system at runtime but is removed when the device is restarted thereby restoring the device to its original state.
FIG. 1 illustrates how a file-based write filter 110 can be employed to prevent the contents of a protected volume on disk 100 from being modified. Disk 100 is intended to generally represent any type of physical storage medium (or volume). In accordance with the Windows architecture, a driver stack consisting of file system driver 111, volume manager 112, and disk driver 113 sit atop disk 100, and I/O manager 120 manages the flow of I/O requests through the driver stack. An application (not shown) can employ file/directory management APIs 160 to invoke a service of system services 130 (e.g., by calling ReadFile, WriteFile, CreateFile, etc. on a particular file) which will result in I/O manager 120 creating an IRP for the request. This IRP will then be passed down through the driver stack.
As depicted in FIG. 1, file-based write filter 110 is positioned at the top of the driver stack and will therefore be able to process an IRP prior to the IRP being passed down to the lower level drivers. It is noted that the architecture would be similar when a sector-based write filter is employed except that the sector-based write filter would sit below file system driver 111. File-based write filter 110 (or equally a sector-based write filter) can be configured to detect writes targeting a protected volume and redirect them to overlay 140 rather than allowing them to be passed down the driver stack. As a result, the write will actually occur in overlay 140 rather than to disk 100. File-based write filter 110 can be further configured to detect reads that target content that has been stored in overlay 140 and redirect these reads to overlay 140. In this way, even though it will appear to the application that the content of disk 100 is being updated, the updates are actually being temporarily maintained in overlay 140. The contents of overlay 140 can be maintained until the operating system is restarted or until an explicit command is received to discard the contents of the overlay.
The size of the overlay employed by the Windows file-based write filter is static and cannot be changed without first rebooting the system. In particular, the FbwfSetCacheThreshold function allows the size of the overlay, in megabytes, to be specified. However, when this function is called, it has no effect on the size of the overlay during the current session. Instead, the specified size of the overlay will not be applied until the next reboot. By default, the size of the overlay will be 64 megabytes and can be increased up to the value of FBWF_MAX_CACHE_THRESHOLD.
One problem that results from the static size of the overlay is that the system will be automatically rebooted if the overlay becomes full. The user will not be presented with an option to reboot in this scenario. Over time, even if the size of the overlay is set to FB_WF_MAX_CACHE_THRESHOLD, it is likely to become full and force the reboot of the system. As a result, the user experience can be greatly degraded when a file-based write filter is employed. Also, if the size of the overlay is set too high, the system may not have enough RAM left to run multiple applications or even the operating system.